1. Field
Example embodiments in general are directed to a method of encapsulating information in records from two or more disparate databases having dissimilar field structures.
2. Related Art
Conventional databases configured to store user-associated information typically employ a proprietary “record” format. A record includes a number of fields which are uniform throughout a particular database. Records typically include (1) fields used to authenticate or identify users, and (2) fields used to store data associated with the users.
In an example, identifying fields may include a “First Name” field, a “Last Name Field”, a “Social Security Number” field, etc., and/or any other well-known identification/authentication signature (e.g., a biometric signature of a user's fingerprint, retinal scan, etc.). In another example, data fields may include “Credit History”, “Medical History”, etc., and/or any other well type of user-associated data.
Databases using the same record fields can be merged with each using a common or shared communications interface protocol (CIP). For example, first and second databases may all include the same, or at least compatible, record field structures. The first and second databases may share and/or merge information, stored in their respective record fields, using a specific CIP because the record field structure of the first and second databases to be combined are identical. In this instance, First Name in database “A” routinely maps to First Name in database “B” or Credit History in database “B” routinely maps to Credit History in database “A”.
However, different databases typically include proprietary record field structures with potentially incompatible field structures. For example, database A might have a different name representing the First name information than database B. (i.e. “Last Name” in Database A versus “Surname” in database B). In such cases, a set of databases cannot be accessed simultaneously using a specific CIP unless the dissimilar database employs a “translator or data mapping” application which establishes a standard associative field structure for both the known and dissimilar field structures. This literally means that the field structure of database “A” is examined along with the field structure of database “B”. Fields in “A” are then physically matched to corresponding fields in “B” to identify to the CIP that both fields' structures have the same type of information. This process is known as data mapping or data translation.
Such data mapping or translator applications are expensive to produce and maintain, and add both complexity and time to inter-database communications. The need to physically map each dissimilar field to an intermediary file can prove burdensome. Even if automated, the time and expense it would take each process to establish the standard and match each dissimilar element to it is significant.
Additionally, record fields are typically stored together in contiguous or adjacent memory address locations, such that identifying fields and data fields are in close, physical proximity to each other within conventional databases. Accordingly, if a conventional database is compromised by a hacker, the hacker can, with relative ease, combine the identifying fields with their associated data fields to obtain the relevance of the data fields.
Conventional techniques to reduce a hacker's success in extracting relevance from compromised data (e.g., by correctly associating compromised data with user-information) typically include adding layers of “active” encryption to database storage protocols. For example, an entire database, storing numerous records, may be encrypted such that the hacker cannot read any information from the database without obtaining a key to decrypt the database.
However, authorized users must also decrypt the database to access the information stored therein, which adds additional processing requirements and delays to database access. Further, if the hacker is able to successfully decrypt the database, the information present within the database becomes available to the hacker in the conventional “ready-to-read” format (e.g., contiguous/adjacent memory address record field storage). Also, if an authorized user loses the key required to decrypt the encrypted database, the authorized user cannot access the database until he/she obtains a replacement key, which can be a laborious process (e.g., requiring re-authentication and distribution of the replacement key).